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US Department of Commerce 
United States Patent and Trademark 
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2011 South Clark Place Room 
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Arlington, VA 22202 
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Date of mailing (day/month/year) 
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International application No. 
PCT/GBOO/00751 


Applicant's or agent* s file reference 
30990059 WO 


International filing date (day/month/year) 
03 March 2000 (03.03.00) 


Priority date (day/month/year) 
05 March 1999 (05.03.99) 


Applicant 

CHEN, Liqun et al 



1. The designated Office is hereby notified of its election made: 

| X | in the demand filed with the International Preliminary Examining Authority on: 

02 October 2000 (02.10.00) 



| | in a notice effecting later election filed with the International Bureau on: 



2. The election | X| was 

| | was not 

made before the expiration of 19 months from the priority date or, where Rule 32 applies, within the time limit under 
Rule 32.2(b). 





Authorized officer 


The International Bureau of WIPO 


34, chemin des Colombettes 


Olivia TEFY 


1211 Geneva 20, Switzerland 




Facsimile No.: (41-22) 740.14.35 


Telephone No.: (41-22) 338.83.38 
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INTERNATIONAL PRELIMINARY EXAMINATION REPORT 

(PCT Article 36 and Rule 70) 



Applicant's or agents file reference 
30990059 WO 


See Notification of Transmittal of International 
FOR FURTHER ACTION Preliminary Examination Report (Form PCT/IPEA/416) 


Internationa] application No. 
PCT/GBOO/00751 


International filing date (day/monWyear) 
03/03/2000 


Priority date (day/month/year) 
05/03/1999 


International Patent Classification (IPC) or national classification and IPC 
G06F1/00 


Applicant 

HEWLETT-PACKARD COMPANY et al. 



1. This international preliminary examination report has been prepared by this International Preliminary Examining Authority 
and is transmitted to the applicant according to Article 36. 

2. This REPORT consists of a total of 5 sheets, including this cover sheet. 

□ This report is also accompanied by ANNEXES, i.e. sheets of the description, claims and/or drawings which have 
been amended and are the basis for this report and/or sheets containing rectifications made before this Authority 
(see Rule 70.16 and Section 607 of the Administrative Instructions under the PCT). 

These annexes consist of a total of sheets. 



3. This report contains indications relating to the following items: 



I 




II 


□ 


III 


□ 


IV 


□ 


V 




VI 


□ 


VII 




VIII 


El 



Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial applicability; 
citations and explanations suporting such statement 



Date of submission of the demand 
02/10/2000 



Date of completion of this report 



23.01.2001 



Name and mailing address of the international 
preliminary examining authority: 
— European Patent Office 

D-80298 Munich 
Tel. +49 89 2399 - 0 Tx: 523656 epmu d 

Fax: +49 89 2399 - 4465 



Authorized officer 
Van de Maele, L 

Telephone No. +49 89 2399 8805 



Form PCT/IPEA/409 (cover sheet) (January 1994) 



INTERNATIONAL PRELIMINARY 
EXAMINATION REPORT 



International application No. PCT/G BOO/00751 



I. Basis of the report 

1 . This report has been drawn on the basis of (substitute sheets which have been furnished to the receiving Office in 
response to an invitation under Article 14 are referred to in this report as "originaiiy filed 0 and are not annexed to 
the report since they do not contain amendments (Ruies 70. 16 and 70.17).): 
Description, pages: 

1 -25 as originally filed 



Claims, No.: 

1-21 as originally filed 

~) Drawings, sheets: 

1/10-1 0/1 0 as originally filed 



2. With regard to the language, all the elements marked above were available or furnished to this Authority in the 
language in which the international application was filed, unless otherwise indicated under this item. 

These elements were available or furnished to this Authority in the following language: , which is: 

□ the language of a translation furnished for the purposes of the international search (under Rule 23.1 (b)). 

□ the language of publication of the international application (under Rule 48.3(b)). 

□ the language of a translation furnished for the purposes of international preliminary examination (under Rule 
55.2 and/or 55.3). 

3. With regard to any nucleotide and/or amino acid sequence disclosed in the international application, the 
international preliminary examination was carried out on the basis of the sequence listing: 

□ contained in the international application in written form. 

□ filed together with the international application in computer readable form. 

□ furnished subsequently to this Authority in written form. 

□ furnished subsequently to this Authority in computer readable form. 

□ The statement that the subsequently furnished written sequence listing does not go beyond the disclosure in 
the international application as filed has been furnished. 

□ The statement that the information recorded in computer readable form is identical to the written sequence 
listing has been furnished. 

4. The amendments have resulted in the cancellation of: 

□ the description, pages: 

□ the claims, Nos.: 



Form PCT/lPEA/409 (Boxes l-VIII, Sheet 1) (July 1998) 



INTERNATIONAL PRELIMINARY 

EXAMINATION REPORT International application No. PCT/G BOO/00751 



□ the drawings, sheets: 

5. □ This report has been established as if (some of) the amendments had not been made, since they have been 
considered to go beyond the disclosure as filed (Rule 70.2(c)): 

(Any replacement sheet containing such amendments must be referred to under item 1 and annexed to this 
report.) 



6. Additional observations, if necessary: 



V. Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial applicability; 
citations and explanations supporting such statement 

1. Statement 

Novelty (N) Yes: Claims 1-21 

No: Claims 

Inventive step (IS) Yes: Claims 1-21 

No: Claims 

Industrial applicability (IA) Yes: Claims 1-21 

No: Claims 



2. Citations and explanations 
see separate sheet 

VII. Certain defects in the international application 

The following defects in the form or contents of the international application have been noted: 
see separate sheet 

VIII. Certain observations on the international application 

The following observations on the clarity of the claims, description, and drawings or on the question whether the 
claims are fully supported by the description, are made: 
see separate sheet 
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INTERNATIONAL PRELIMINARY International application No. PCT/G BOO/00751 

EXAMINATION REPORT - SEPARATE SHEET 



Cited documents: 

D1: WO 95 24696 A 
D2: US 5 864 624 A 



ANNEX TO SECTION V 

1 The assessment in respect of Article 33 PCToi the claims has been based on 
claims which are amended to overcome the clarity deficiencies as discussed in 
section VIII. 

2. The claims define a token based solution for authorizing access to a computing 
apparatus and more in particular access to a secure process which requires 
several tokens. 

D1 , which is considered the closest prior art document, already describes token 
based access authorization, and it is known from D2 to repeat authorization 
verification during the time of access. The invention however further defines 
features which solve the problem of authorization verification in case the token, on 
which the authorization check was based, is to be (temporarily) replaced by other 
(auxiliary) tokens during the access time. Neither D1 or D2 or any of the other 
documents cited in the International Search Report describe or suggest these 
features and therefore the claims meet the requirements of Article 33 PCT. 



ANNEX TO SECTION VII 



1 . Contrary to the requirements of Rule 5. 1(b)(H) PCT, the relevant background art 
disclosed in the documents D1 and D2 is not or only partially mentioned in the 
description and these documents are not identified therein. 

2. Independent claims are not in the two-part form in accordance with Rule 6.3(b) 
PCT with those features known in combination from the prior art (document D1) 
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INTERNATIONAL PRELIMINARY International application No. PCT/G BOO/00751 
EXAMINATION REPORT - SEPARATE SHEET 



being placed in the preamble (Rule 6.3(b)(i) PCT) and with the remaining features 
being included in the characterising part (Rule 6.3(b)(ii) PCT). 

3. The features of the claims are not provided with reference signs placed in 
parentheses (Rule 6.2(b) PCT). 

4. The statement in the last paragraph of page 25 of the description implies that the 
subject-matter for which protection is sought may be different to that defined by 
the claims, thereby resulting in lack of clarity of the claims (Article 6 PCT) when 
used to interpret them (see the Guidelines PG-lll,4.3a). This statement should 
therefore be amended to remove this inconsistency. 



ANNEX TO SECTION VIII 



1.a The definition of claim 1 (lines 10 to 1 1) suggests that the interface means can 
only receive primary tokens. It is however clear from the description and it is also 
required by further features in claim 1 that these interface means can also receive 
the auxiliary tokens. Therefore, claim 1 lacks of clarity in this respect, Article 6 
PCT. 

1 .b Furthermore, it is clear from the description that only exchanging of the primary 
token by one of the auxiliary tokens identified on that primary token will allow the 
user to continue working with the secure process. More in particular, the 
authorization of these auxiliary tokens is based on the fact that they are identified 
by the primary token. 

However, according to the definition in claims 1 and 15 also other auxiliary 
tokens, not identified on the primary token, could give authorization to work with 
the secure process. Should this be the case then it should be defined how their 
authorization is established. Since there is no such definition, these claims lack 
of clarity, Article 6 PCT. It appears that the claims, in correspondence with the 
description, should have defined that access authorization will only be continued 
for auxiliary tokens which are identified on the primary token. 
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PCT 

REQUEST 



The undersigned requests that the present 

international application be processed 
according to the Patent Cooperation Treaty. 



International Application No. 



EL652176548US 
» For receiving use only 



International Filing Date 



Name of receiving Office and «PCT International Application" 



I Applicant's or agent's file reference 
(if desired) (12 characters maximum) 30990059 WO 



Box No. I TITLE OP INVENTION 

Computing Apparatus and Methods of Operating Computing Apparatus 



Box No. II APPLICANT 

Name and address: (Family name mowed by wen %™&°%f%* f^^tr^thi 

of residence is indicated below.) 

Hewlett-Packard Company 
3000 Hanover Street 
Palo Alto 
CA 94304 
US 



|~| This person is also inventor. 



Telephone No. 



Facsimile No. 



Teleprinter No. 



State (that is, country) of nationality: 
US 



State (that is, country) of residence: 
US 



7his person is applicant p, a? I design^ fg] agSgca □ tFSSSLV 
for the purposes of: I — > bmies 1 



□ the States indicated in 
the Supplemental Box 



w. purposes -- 

toNo.ni FU RTHER APPLICANT^ AND/OR (FURTHER) INVENTORY 

entity, fitll official 




of residence is indicated below.) 



CHEN, Uqun 
1 Harvest Close 
Bradley Stoke 
Bristol BS32 9DQ 
GB 

State (that is, country) of nationality 
CN 



This person is: 

| ^ applicant only 

[jtf] applicant and inventor 

□ inventor only fff this check-box 
is marked, do not fill in below.) 



j State (that is, country) of residence: 
GB 



This person is applicant 
for the purposes of: 



□ all designated I 1 all designated States except 
States I I the Unifed States of America 



rTTl the United States 
\&\ of America only 



□ the States indicated in 
t 



the Supplemental Box 



^ Further appl icants and/or (further) inventors are indicated on a continuation sheet 
vlm tin iv AGENT OR COMMON REPRESENTATIVE; OR ADDRESS FOR CORRESPONDENCE 



The oerson identified below is hereby/has been appointed to act on behalf 
of fflS [ before the competent International Authont.es as: 



Qtf] age"* CD coramon representative 



Name and : 



LAWRENCE, Richard Anthony 
Hewlett-Packard Limited 
Intellectual Property Section 
Rlton Road 

Stoke Gifford, Bristol BS34 8QZ 
GB 



Telephone No. 

+44 117-312-8295 



Facsimile No. 

+44 117-312-8941 



Teleprinter No. 



Form PCT/RO/101 (first sheet) (Jury 1998; reprint January 2000) 



Sheet No 

l^^^PLICANT(S) AND/OR (FURTHER) I NVENT 



If none of the following sub-boxes is used, this sheet should not be included 



Continuation of Box No. Ill FURT 



d firth e 



request 




of residence is indicated below.) 



KWONG LO. Hoi 

c/o MagiQ Technologies, Inc. 

Research & Development 

275 Seventh Avenue, 26th Floor 

New York, NY 10001-6708 

US 



This person is: 

| | applicant only 

|y | applicant and inventor 

□ inventor only (If Ms check-box 
is marked, do not fill m below.) 



State (that is, country) of nationality: 
ICN 



This person is applicant 
for the purposes of: 



State (that is, country) of residence: 
(US 



H the United States 
of America only 



□ 



the States indicated in 
the Supplemental Box 




of residence is indicated below.) 



I CHAN, David 
116112 Mays Avenue 
I Monte Sereno 
I California 
|CA 95030 
US 



This person is: 

| | applicant only 

[y| applicant and inventor 

□ inventor only (If this check-box 
is marked, do not fill in behw.) 



\ State (mat is, country) of nationality: 
GB 

I This person is applicant 
l for the purposes of. 



State (that is, country) of residence: 
I US 



□ a ii A^ippat^t | 1 all designated States except 
a^ignaiea j^j^ Uin gf states of America 



□ the United States 
of America only 



□ the States indicated in 
the Supplemental Box 



Name and address: (Ft 
designation. Theaddru~. — — — 
address indicated in this Box is the app 
of residence is indicated below.) 




This person is: 
| | applicant only 

| j applicant and inventor 

□ inventor only Of this check-box 
is marked, do not fiU in below.) 



i State (mat is, country) of nationality: 



State (that is, country) of residence: 



for the purposes of: I— I &laics ' — 1 



: purposes 

[ Name and address 
designation. Thej 
address indicated •» - -. 

of residence is indicated below.) 




This person is: 

| | applicant only 

i applicant and inventor 



□ 
□ 



inventor only (If this check-box 
is marked, do not fill in below.) 



State (that is, country) of residence: 



State (mat is, country) of nationality: 

. M . , #K _ i info*! states I I the States indicated in 

This pe,son is applicant p. aU^i^ Q D of a£S& °°»y □ *c Supplant Box 

for the Diirposes of: I — I bUUes 1 — ' 



□ Further applicants and/or (further) inv entors are indicated on another continuation sheet. 
Form PCT/RO/101 (continuation sheet) (Jury 1998; reprint January 2000) 



See Notes to the request form 



UnrNo^V O BSIGNATION OP STTAl 
The following designations are hereby made! 
Regional" Patent 



fc Rule 4.9(a) (mark the applicable cheek-bom. at led 



I be markedh 



QQ EP 



Convention and of the PCT 
European Patent: AT Austria, BE Bd^iu^ 

Convention and of the PCT ... ^ m Cote d'lvoire, CM Cameroon, 

n OA OAPI Patent: BF Burkina 1 

specify on dotted line) 
National Patent (ifo&er kind of protection or 

□ AE United Arab Emirates 

□ AL Albania 

□ AM Armenia 

□ AT Austria 

Q AU Australia 

Azerbaijan 



treatment desired, specify on dotted line) : 
□ LR Liberia 



□ LS 

□ LT 

□ LU 

□ LV 

□ MA 



, T » • n MD Republic of Moldova 

Bosnia and Herzegovina ' - - 

Barbados U MC 



□ AZ 

□ BA 

□ BB 

□ BG Bulgaria 

□ BR Brazil . 

□ BY Belarus 

□ CA Canada 

□ CH and LI Switzerland and Liechtenstein n m 
z£ . LJ NO 

□ CN China n 

OCR Costa Rica J=| 

□ CU Cuba {=} 

□ CZ Czech Republic „ 

□ DE Germany J=J 

□ DK Denmark " ™ 

□ DM Dominica Jd 

□ EE Estonia " 

□ ES Spain ^ SG 

□ FI Finland M 

□ GB United Kingdom " ^ 

□ GD Grenada g TJ 

□ GE Georgia - • • 

□ GH Ghana 

□ GM Gambia " ^ 

□ HR Croatia 
Hungary 



Lesotho . - - 
Lithuania 
Luxembourg 
Latvia 

Morocco . . . 



□ MK The former Yugoslav Republic of Macedonia 



□ HU 

□ ID 

□ IL 

□ IN 

□ IS 
0 JP 

□ KE 

□ KG 



Indonesia n yG 

Isracl . . B US 
India 

Iceland 



□ MN Mongolia 

□ MW Malawi 

□ MX Mexico 

Norway 

New Zealand 

Poland 

Portugal 

Romania 

Russian Federation 

Sudan 
Sweden 
Singapore 

Slovenia 

Slovakia 

Sierra Leone 

Tajikistan 

Turkmenistan 

□ TR Turkey 

Trinidad and Tobago 

United Republic of Tanzania 

Ukraine 

Uganda 

United States of America . . 



□ TZ 

□ UA 



**** .... □ VN 

Kenya □ YU 

Kyrgyzstan "_/ *..'„'*" □ ZA 



□ KP Democratic People's Republic of Korea j=j ^ 



Check-boxes reserved for designating States 
become party to the PCT after issuance of this sheet. 



which have 



□ UZ Uzbekistan . 

Viet Nam - . 
Yugoslavia . 
South Africa 
Zimbabwe . . 
_ reserved 

□ KR Republic of Korea 

□ KZ Kazakhstan Q 

□ LC Saint Lucia Q 

□ LK Sri Lanka , J . .. „ maH( . fltvwc the anolicant also makes under Rule 4.9(b) all other 
SLunonary DesignationStatement: In addiW ^^g^SftcS^lcm^^^^ 
designations which would be permitted under the rcT«^tany^na ^ designations are subject to confirmation and that any 
fonfttie scope of this statement. The applicant d ~^"^ *^^^ e ^orrty ^ * to be regarded as w^dnrwr. by the apphcant 

Snatio" which is not confirmed teforetheexp^onof ^J^^^^office ^AelS^onA time limit) 

£trfeWon of that time lirnit (Corfrma**, QnJudmefees) must read, toerecewg j, _ See Note* to the reauestjorm 
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Sheet No. 



^ m» VI PRIORITY CLAIM 



Fifing date 
of earlier application 
(day/monthfyear) 



PI Further priori! ^jf " ,he Suoolementd Box. 

•^^Harion 



Nufl 

of eartier application 



Where earlier 



national application: 
count 



regional application:* 
regional Office 



international application: 
receiving Office 



item (3) 

— — „« * o^nnu^ authority _ . ■ 



\^xmvenuan * ^ 7 

■ Birir - «m TMTRttNATlONAL SEA BfT * INt * AUTHORITY 



▼ *•* 

ChdceoflnternationalSear^gAathe^aSA) 

Of tm> or more International Search,** ^™° rl <" a Z 
Lmaetent to carry out the international learch, Int 
tT&£or% chain, the two-letter code may be used) 



LUltl UKI 1 1 .. I 



Date (day/monthfyear) 

17 September 1999 



Number 
9905056.9 



Country (or regfema! Office) 

GB 



This international application is accompanied by the hen*) marked below. 
1 . El &c calculation sheet 

2 Q separate signed power of attorney 

3 . 0 copy of general power of attorney, reference number, if any 

4 □ statement explaining lack of signature 

5 0 priority document) identified in Box No. Vlasitem(s): 1 

6 □ translation of international application into (language): 

7 Q separate mdications concennng deputed m.croorgan.sm or other b^ca, matenal 

8. □ nucleotide and/or amino acid sequence fisting in computer readable form 

9. Q other (specify): GB Search Report 

jaaggg 

n^^rx SIGNATURE ^^^^^^^ ^ , rf r,-- r -^^M^f^^""*™' 

Next to each s,gnaturt. indicate the name of the perzon irgntng anft^ capacxry ^ 



request 

description (exctoding 
sequence listing part) 

claims 

abstract 

drawings 

sequence listing part 
of description 



Total number of sheets : 44 

Figure of the drawings which 
should accompany the abstract: o 




Ridhard Anthony Lawrence 



1 . Date of actual receipt of the purported 
international application: 



For receiving Office use only < 



5 International Searching Authority to a / 
(if two or m ore are competent): LkJi ^ / 

Date of receipt of the record copy 
by the International Bureau: 



■ uy tut. uiiwiiwv— — m^^^^ m 

Form PCT/RO/101 (last sheet) (July 1998, reprint January ^ 
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PCT 

DEMAND 



CHAPTER H 



The rm*~*~~A under Article 3 1 of the Patent Cooperation Treaty 



For fatemalional Preliminary Examining Authority use only 
jjate of receftrt ofDEMAND 



[ Identification of IPBA 

BoxNo. I IDENTIFICATION OF THE INTERNATIONAL APPLICATION 



International filing date (dayfmsmth/year) 
3rd March 2000 (03/03/00) 



International application No. 
PCT/GB OO/00751 
^ | Title of invention 

Computing Apparatus and Methods of O perating Computing Apparatus 
j Box No. D APPUCANT(S) 



Applicant's or agent's file reference 
30990059 WO 



(Earliest) Priority date (aay/month/year) 
5th March 1999 (05/03/99) 



! Name and address: 



Tne address must include postal code and r. 



■ —or" ~'~"jt jin 

name of country J 



Hewlett-Packard Company 
3000 Hanover Street 
Palo Alto 
CA 94304 
US 

State (that is, country) of nationality: 
US 



Telephone Na: 



Tefeprinta* No.: 



State (that is, country) of residence: 
US 



Facsimile No.: 



1 Harvest Close 
Bradley Stoke 
Bristol BS32 9DQ 
GB 



State (that is, country) of nationality : 
CN 

Name and address: (Family name followed by given 

KWONG LO, Hoi 
c/o MagiQ Technologies, Inc. 
Research & Development 
275 Seventh Avenue, 26th Floor 
New York. NY 10001-6708 
US 



State (that is, country) of residence: 
GB 



V Male&errtty.fanojJlcialdesignaHon. Ine address must incJudepostal code and name of country.) I 



State (thai is, country) of nationality 
CN 



0 

Further applicants are indicated on a continuation sheet 
Form PCT/IPEA/40I (Cist sheet) (July 1998; reprint July 19997 



State (that is, country) of residence- 
US 



See Notes to the demand form 



# 



Sheet No. 



International application No. 

PCT/GB00/00751 



Continuation of Box No. II APPLICANT® 



If none of the following sub-boxes is used, this sheet should not be included in the demand. 



Name and address: (Family name foiled by given nam e; for a legal entity, fid! official designation. The address mutt Include postal code and name of country ) 

CHAN, David 



16112 Mays Avenue 




Monte Sereno 




California 




CA 95030 




US 




State (that fs t country) of nationality: 


State (that is, country) of residence: 


GB 


us 



Name and address: (Family nam, folded by given name; for a legal entity, full official designation. The address must Include postal code and name of country) 



State (that is, country) of nationality: 



State (that is, country) of residence: 



Name and address: (Farnily name followed by given name; for a legal entity, Jul! oJficiaJ designation. The address must include postal code and name of country) 



State (that is, country) of nationality: 



State (that is, country) of residence: 



Name and address: (Family name followed by given name; for a legal entity, fun official designation. The address must include postal code and name of country.) 



State (that is, country) of nationaHty: 



State (that is, country) of residence: 



J Further applicants are indicated on another continuation sheet 

FormPCT/IPEA/401 (continuation sheet) ( July 1 998; reprintJuly 1999) 



See Notes to the demand form 



o I Intemalional application No. 

Sheet No. . I 

aneci . PCT/G BOO/00751 



Box No. ni AGENT OR COMMON REPRESENTATIVE; OR ADDRESS FOR CORRESPONDENCE 



The following person is gfj agent common representative 

and [5] has been appointed earlier and represents the applicants) also for international preliminary examination 

□ 

is hereby appointed and any earlier appointment of (an) agent(3)/common representative is hereby revoked. 

CH 2 hereby appointed, specifically for the procedure before the International Pnrfiminary Examining Authority, in addition to 
the agent( sycemmon representative appointed earlier. 



Name and address: (Family name followed by given name; for a legal entity, fall official designation 
lite address must include postal code and name of country J 

LAWMAN, Matthew John Mitchell 
Hewlett-Packard Limited 
Intellectual Property Section 
Filton Road, Stoke Grfford 
Bristol BS34 8QZ 
GB 



Telephone No.: 

+44-117-312-8026 



Facsimile No.: 

+44-117-312-8941 



Teleprinter Na: 



I I Address for correspondence: Mark this check-box where no agent or common represen t ati ve is/has been appointed and the 
1 — 1 space above is used instead to indicate a special address to which correspondence should be sent 



Box No. IV BASIS FOR INTERNATIONAL PRELIMINARY EXAMINATION 



Statement concerning amendments:* 

1. The applicant wishes the international preliminary examination to start on the basis of: 
the international application as originally filed 
the description □ as originally filed 

I I as amended under Article 34 

the claims | as originally filed 

| as amended under Article 19 (together with any accompanying statement) 
I as amended under Article 34 

the drawings | I as originally filed 

I 1 as amended under Article 34 

The applicant wishes any a m e n d me nt to the claims under Article 19 to be considered as reversed. 

3 - The a pplicant wishes the start of the international preliminary examination to be postponed until the expiration of 20 months 

from the priority date unless the International Preliminary Examining Authority receives a copy of any ammAn^ made 
under Article 1 9 or a notice from the applicant that he does not wish to make such amendments (Rule 69. 1 (d)). (Tfiis check- 
box may be marked only where the time limit under Article 19 has not yet expired) 

Where no check-box is marked, international prdirninary examination will start on the basis of the international application 
as originally filed or, where a copy of amendments to the claims under Article 19 and/or amendments of the intemationai application 
under Article 34 are received by the International Prelirnmary Examining Authority before it has begun to draw up a written opinion 
or the international preliminary examination report, as so amended. 



Language for the purposes of international preliminary examination: English 
QjT] which is the language in which the international application was filed. 

□ 

which is the language of a translation furnished for the purposes of intemationai search. 
r"j which is the language of publication of the intemationai application. 

I 1 which is the language of the translation (to be) furnished for the purposes of international prelmiinary examination. 



Box No. V ELECTION OF STATES 



The applicant hereby elects ail eligible States (that is. ail States which have been designated and which are bound by Chapter 2T of 
thePCT) J 

excluding the following States winch the applicant wishes not to elect: 
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(57) Abstract 

Computing apparatus comprises a memory means storing the in- 
structions of a secure process and an authentication process; a processing 
means arranged to control the operation of the computing apparatus in- 
cluding by executing the secure process and the authentication process; a 
user interface means arranged to receive user input and return to the user 
information generated by the processing means in response to the user 
input; and an interface means for receiving a removable primary token 
and communication with the token. The token comprises a body sup- 
porting a token interface for communicating with the interface means, a 
token processor, and a token memory adapted to store token data includ- 
ing information for identifying the token and auxiliary token informa- 
tion identifying one or more authorised auxiliary tokens. The processing 
means is arranged to receive the identity information and the auxiliary to- 
ken information from the primary token, to authenticates the token using 
the authentication process and, if the token is successfully authenticated, 
permit a user to interact with the secure process via the user interface 
means. The processing means is arranged to repeatedly authenticate the 
primary token and cause the computing platform to suspend interaction 
between the secure process and the user if authentication is not possible 
as a result of the removal of the primary token unless the primary token 
is replaced by an authorised auxiliary token. 
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COMPUTING APPARATUS AND METHODS USING SECURE AUTHENTICATION ARRANGEMENT 

Technical Field 

5 This invention relates to computing apparatus and particularly, but not 

exclusively, to computing apparatus and methods of operating computing apparatus 
in a secure environment using security tokens. 

Background Art 

10 Security tokens, for example smart cards or cryptographic co-processors, 

have recently been proposed for various security functions including accessing 
computer platforms (or 'host platforms') and electronic commerce. For instance, a 
smart card storing confidential information accessible only to a related user can be 
used by the user to log on to a computer, to sign a document, or to provide 

15 credentials needed for electronic commerce. 

In some cases, it is expected that more than one security token for plural 
different applications may need to be used in a single communication session, which 
starts as the user logs on to a host platform and finishes as the user logs off. 

One possible model works as follows. A user has a number of tokens and, in 

20 each session, they use one of these tokens (for example, a logon token) for 
authentication to a host platform in the logon process only. During the same session, 
the user separately uses other tokens (for example, auxiliary tokens) for other 
security functions, such as electronic payment or cryptography. 

25 Disclosure of the Invention 

In arriving at the present invention, the present inventors have appreciated 
the following three potential problems with this model: 

Problem A - there is an inherent danger of a user walking away after logging 
on to the host platform, thus allowing an impostor to use the platform. 
30 Problem B - a fake host platform may be able to steal sensitive information 

from the user. 

Problem C - there are some auxiliary tokens whose owner's identities are not 
traceable to the owner of the logon token, in other words, an impostor, who does not 
own the logon token, may be able to use his own auxiliary tokens to impersonate the 
35 logon token's owner. 
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In addressing one or more of the above problems, the present inventors 
propose a new arrangement to reduce security risk and to establish a more trusted 
relationship between a host platform and a plurality of security tokens. Typically, the 
arrangement implements a security control policy that is more refined than the policy 
5 in the prior art model, including periodic or repeated authentication. Preferred 
embodiments of the invention implement mutual authentication and privilege 
restriction. Of particular importance are the criteria of ease of use and low expense 
of implementation compared with prior art solutions. 

In a first aspect, the invention provides computing apparatus comprising: 

10 memory means storing the instructions of a secure process and an authentication 
process; processing means arranged to control the operation of the computing 
apparatus including by executing the secure process and the authentication process; 
user interface means arranged to receive user input and return to the user 
information generated by the processing means in response to the user input; and 

15 interface means for receiving a removable primary token and communicating with the 
token, the token comprising a body supporting: a token interface for communicating 
with the interface means; a token processor; and token memory storing token data 
including information for identifying the token and auxiliary token information 
identifying one or more authorised auxiliary tokens, wherein the processing means is 

20 arranged to receive the identity information and the auxiliary token information from 
the primary token, authenticate the token using the authentication process and, if the 
token is successfully authenticated, permit a user to interact with the secure process 
via the user interface means, and wherein the processing means is arranged to 
repeatedly authenticate the primary token and cause the computing platform to 

25 suspend interaction between the secure process and the user if authentication is not 
possible as a result of the removal of the primary token unless the primary token is 
replaced by an authorised auxiliary token. 

In a second aspect, the invention provides a method of controlling computing 

apparatus to authenticate a user, comprising the steps of: 
30 the computing apparatus receiving a primary token of the user, the primary 

token containing information suitable for authenticating the primary token and 

information relating to one or more authorised auxiliary tokens; 

if the token is authentic, permitting the user to interact with one or more 

secure applications that may be executed by the computing platform; 
35 at intervals, re-authenticating the primary token; and 
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if it is not possible to re-authenticate the primary token, suspending the 
interaction between the computing apparatus and the user unless the primary token 
has been replaced with an authorised auxiliary token. 

In a third aspect, the invention provides a smart card programmed for 
5 operation as a primary token in accordance with the method set out above. In a 
fourth aspect, the invention provides a computing apparatus configured for operation 
in accordance with the method set out above. 

10 Brief Description of the Drawings 

Preferred embodiments of the present invention will now be described, by way of 
example only, with reference to the accompanying drawings, of which: 

Figure 1 is a diagram that illustrates a system capable of implementing 
15 embodiments of the present invention; 

Figure 2 is a diagram which illustrates a motherboard including a trusted 
device arranged to communicate with a smart card via a smart card reader and with 
a group of modules; 

Figure 3 is a diagram that illustrates the trusted device in more detail; 
20 Figure 4 is a flow diagram which illustrates the steps involved in acquiring an 

integrity metric of the computing apparatus; 

Figure 5 is a flow diagram which illustrates the steps involved in establishing 
communications between a trusted computing platform and a remote platform 
including the trusted platform verifying its integrity; 
25 Figure 6 is a diagram that illustrates the operational parts of a logon smart 

card for use in accordance with embodiments of the present invention; 

Figure 7 is a flow diagram which illustrates the process of mutually 
authenticating a logon smart card and a host platform; 

Figure 8 is a flow diagram which illustrates one general example of 
30 introducing an auxiliary smart card to a host platform using by a logon smart card in 
accordance with embodiments of the invention; 

Figure 9 is a flow diagram which illustrates one example of the operation 
between an introduced cash card and the host platform; 

Figure 10 is a flow diagram which illustrates one example of a single session 
35 temporary delegation mode; and 
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Figure 11 is a flow diagram which illustrates one example of a multiple 
session temporary delegation mode. 

5 Best Mode For Carrying Out the Invention, & Industrial Applicability 

While the ideas of the invention are general, for ease of discussion, we will 
focus on preferred embodiments, wherein smart cards are the security tokens, which 
interact with a computing platform, or simply "platform". For the purpose of this 
specification, a computing platform is used to refer to at least one data processor and 

10 at least one data storage means, usually but not essentially with associated 
communications facilities e.g. a plurality of drivers, associated applications and data 
files, and which may be capable of interacting with external entities e.g. a user or 
another computer platform, for example by means of connection to the internet, 
connection to an external network, or by having an input port capable of receiving 

15 data stored on a data storage medium, e.g. a CD-ROM, floppy disk, ribbon tape or 
the like. In the arrangements described, a user has one logon smart card and a 
number of auxiliary smart cards, and needs to interact with the platform, which has 
only a single smart card reader. It is assumed in the present embodiment that there 
is no way for more than one smart card to be read by the smart card reader at the 

20 same time. 

In order to address Problem A, as set out in the "Disclosure of the Invention", 
the present embodiments implement a coherent security control policy using a logon 
smart card operating with the platform. Specifically, to limit the potential for an 
impostor getting access to the platform without the legitimate user's knowledge, the 
25 logon smart card needs to be present throughout the session, rather than just to 
initiate the session. By analogy, the logon smart card is used more like a car key 
than a door key. 

In effect, a user is held responsible for their actions. Since the smart card has 
to be present during the execution of a command, this effectively and unambiguously 
30 holds the owner of the smart card responsible for the action. As will be described 
below, in preferred embodiments the authentication is done automatically by the 
platform and does not generally require actions from the user. This amounts to a 
saving of time for the user and is, thus, a very attractive feature. 

A major strength of the proposed scheme lies in its intuitive appeal. People 
35 are familiar with the importance of protecting their keys and accept full responsibility 
for respective misuse of the keys. The present scheme, which greatly enhances 
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security, is simple to implement. As an added security feature, it is preferable that 
the logon smart card is also password protected, requiring a user to enter a 
password when the card is first inserted into the smart card reader. Password 
techniques are well-known and will not be described herein, so as not to obscure the 
5 invention. 

Generally, to check the presence of the logon smart card, the platform needs 
repeatedly to authenticate the logon card. The actual frequency of the authentication 
can be configured by either a system administrator or the user. In practice, one 
would set the frequency high enough that the user, or an unauthorised user, would 

10 be unable to subvert the platform and carry out an unauthorised transaction between 
authentications. For example, authentication may occur every few seconds. 

A further security feature that can be implemented in the security policy is a 
time-limit for each authenticated session using an auxiliary smart card. The user 
interface may also be locked unless a new round of authentication is performed 

15 within the pre-set time-limit Further, preferably, time-stamping, or the use of nonces, 
is used to prevent "replay attacks" during authentication. 

To address the fake host platform problem, Problem B above, the preferred 
embodiments use the concept of a trusted device built into the platform, which allows 
a user to verify the integrity of the platform. The concept of such a trusted device is 

20 the subject of the applicant's co-pending International Patent Application No. ## 
entitled "Trusted Computing Platform" filed on 15 February 2000, the entire contents 
of which are hereby incorporated herein by reference. 

To address Problem C, as set out in the "Disclosure of the Invention", where 
an auxiliary smart card may not be traceable to the owner of the logon smart card, 

25 the present invention introduces the concept of a user profile that binds a user to a 
number of auxiliary smart cards. This makes the implementation of a coherent, 
comprehensive and flexible security control policy extremely simple, inexpensive and 
transparent to the user. 

Generally, in the preferred embodiments, it is always assumed that logging on 

30 is done by a logon smart card, and at some point of the session, the user (or the 
application running under the session) needs to use one or more auxiliary smart 
cards, so that removal of the logon card becomes necessary. To maintain the 
security policy of repeated authentication, there needs to be a security chain for the 
platform between trusting the logon smart card and trusting other auxiliary smart 

35 cards. This chain is built by letting the logon smart card introduce' the auxiliary 
cards to the platform, for example by using 'user profiles'. 
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For the sake of simplicity of description, only two types of auxiliary smart 
cards are considered in any detail herein: 

"Cash cards", which are smart cards having cash values (or credits) that are 
transferable; and 

"Crypto cards", which are smart cards whose privileges (such as encryption or 
signature supported by a private key) are not transferable. 

A "trusted platform" used in preferred embodiments of the invention will now 
be described. This is achieved by the incorporation into a computing platform of a 
physical trusted device whose function is to bind the identity of the platform to reliably 
measured data that provides an integrity metric of the platform. The identity and the 
integrity metric are compared with expected values provided by a trusted party (TP) 
that is prepared to vouch for the trustworthiness of the platform. If there is a match, 
the implication is that at least part of the platform is operating correctly, depending on 
the scope of the integrity metric. 

A user verifies the correct operation of the platform before exchanging other 
data with the platform. A user does this by requesting the trusted device to provide 
its identity and an integrity metric. (Optionally the trusted device will refuse to provide 
evidence of identity if it itself was unable to verify correct operation of the platform.) 
The user receives the proof of identity and the identity metric, and compares them 
against values which it believes to be true. Those proper values are provided by the 
TP or another entity that is trusted by the user. If data reported by the trusted device 
is the same as that provided by the TP, the user trusts the platform. This is because 
the user trusts the entity. The entity trusts the platform because it has previously 
validated the identity and determined the proper integrity metric of the platform. 

Once a user has established trusted operation of the platform, he exchanges 
other data with the platform. For a local user, the exchange might be by interacting 
with some software application running on the platform. For a remote user, the 
exchange might involve a secure transaction. In either case, the data exchanged is 
'signed' by the trusted device. The user can then have greater confidence that data 
is being exchanged with a platform whose behaviour can be trusted. 

The trusted device uses cryptographic processes but does not necessarily 
provide an external interface to those cryptographic processes. Also, a most 
desirable implementation would be to make the trusted device tamperproof, to 
protect secrets by making them inaccessible to other platform functions and provide 
an environment that is substantially immune to unauthorised modification. Since 
tamper-proofing is impossible, the best approximation is a trusted device that is 
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tamper-resistant, or tamper-detecting. The trusted device, therefore, preferably 
consists of one physical component that is tamper-resistant. 

Techniques relevant to tamper-resistance are well known to those skilled in 
the art of security. These techniques include methods for resisting tampering (such 
5 as appropriate encapsulation of the trusted device), methods for detecting tampering 
(such as detection of out of specification voltages, X-rays, or loss of physical integrity 
in the trusted device casing), and methods for eliminating data when tampering is 
detected. Further discussion of appropriate techniques can be found in "Tamper 
Resistance - a Cautionary Note", by Ross Anderson and Markus Kuhn, published in 

10 the Second USENIX Workshop on Electronic Commerce Proceedings, Oakland, 
California, November 1996, pp 1-11, ISBN 1-880446-83-9. It will be appreciated 
that, although tamper-proofing is a most desirable feature of the present invention, it 
does not enter into the normal operation of the invention and, as such, is beyond the 
scope of the present invention and will not be described in any detail herein. 

15 The trusted device is preferably a physical one because it must be difficult to 

forge. It is most preferably tamper-resistant because it must be hard to counterfeit. It 
typically has an engine capable of using cryptographic processes because it is 
required to prove identity, both locally and at a distance, and it contains at least one 
method of measuring some integrity metric of the platform with which it is associated. 

20 A trusted platform 10 is illustrated in the diagram in Figure 1. The platform 10 

includes the standard features of a keyboard 14, mouse 16 and visual display unit 
(VDU) 18, which provide the physical 'user interface' of the platform. This 
embodiment of a trusted platform also contains a smart card reader 12 - a smart card 
reader is not an essential element of all trusted platforms (not all trusted platforms 

25 employ smart cards), but is employed in various preferred embodiments described 
below and of relevance to the present invention. Alongside the smart card reader 12, 
there is illustrated a smart card 19 and one (possibly of several) auxiliary smart cards 
17 to allow trusted user interaction with the trusted platform as shall be described 
further below. In the platform 10, there are a plurality of modules 15: these are other 

30 functional elements of the trusted platform of essentially any kind appropriate to that 
platform (the functional significance of such elements is not relevant to the present 
invention and will not be discussed further herein). 

As illustrated in Figure 2, the motherboard 20 of the trusted computing 
platform 10 includes (among other standard components) a main processor 21, main 

35 memory 22, a trusted device 24, a data bus 26 and respective control lines 27 and 
lines 28, BIOS memory 29 containing the BIOS program -for the platform 10 and an 
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Input/Output (IO) device 23, which controls interaction between the components of 
the motherboard and the smart card reader 12, the keyboard 14, the mouse 16 and 
the VDU 18. The main memory 22 is typically random access memory (RAM). In 
operation, the platform 10 loads the operating system, for example Windows NT™, 
5 into RAM from hard disk (not shown). Additionally, in operation, the platform 10 
loads the processes or applications that may be executed by the platform 10 into 
RAM from hard disk (not shown). 

Typically, in a personal computer the BIOS program is located in a special 
reserved memory area, the upper 64K of the first megabyte do the system memory 

10 (addresses F000h to FFFFh), and the main processor is arranged to look at this 
memory location first, in accordance with an industry wide standard. 

The significant difference between the platform and a conventional platform 
is that, after reset, the main processor is initially controlled by the trusted device, 
which then hands control over to the platform-specific BIOS program, which in turn 

15 initialises all input/output devices as normal. After the BIOS program has executed, 
control is handed over as normal by the BIOS program to an operating system 
program, such as Windows NT (TM), which is typically loaded into main memory 22 
from a hard disk drive (not shown). 

Clearly, this change from the normal procedure requires a modification to the 

20 implementation of the industry standard, whereby the main processor 21 is directed 
to address the trusted device 24 to receive its first instructions. This change may be 
made simply by hard-coding a different address into the main processor 21. 
Alternatively, the trusted device 24 may be assigned the standard BIOS program 
address, in which case there is no need to modify the main processor configuration. 

25 It is highly desirable for the BIOS boot block to be contained within the trusted 

device 24. This prevents subversion of the obtaining of the integrity metric (which 
could otherwise occur if rogue software processes are present) and prevents rogue 
software processes creating a situation in which the BIOS (even if correct) fails to 
build the proper environment for the operating system. 

30 Although, in the preferred embodiment to be described, the trusted device 24 

is a single, discrete component, it is envisaged that the functions of the trusted 
device 24 may alternatively be split into multiple devices on the motherboard, or even 
integrated into one or more of the existing standard devices of the platform. For 
example, it is feasible to integrate one or more of the functions of the trusted device 

35 into the main processor itself, provided that the functions and their communications 
cannot be subverted. This, however, would probably require separate leads on the 
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processor for sole use by the trusted functions. Additionally or alternatively, although 
in the present embodiment the trusted device is a hardware device that is adapted for 
integration into the motherboard 20, it is anticipated that a trusted device may be 
implemented as a 'removable' device, such as a dongle, which could be attached to 
5 a platform when required. Whether the trusted device is integrated or removable is a 
matter of design choice. However, where the trusted device is separable, a 
mechanism for providing a logical binding between the trusted device and the 
platform should be present. 

The trusted device 24 comprises a number of blocks, as illustrated in Figure 

10 3. After system reset, the trusted device 24 performs a secure boot process to 
ensure that the operating system of the platform 10 (including the system clock and 
the display on the monitor) is running properly and in a secure manner. During the 
secure boot process, the trusted device 24 acquires an integrity metric of the 
computing platform 10. The trusted device 24 can also perform secure data transfer 

15 and, for example, authentication between it and a smart card via 
encryption/decryption and signature/verification. The trusted device 24 can also 
securely enforce various security control policies, such as locking of the user 
interface. 

Specifically, the trusted device comprises: a controller 30 programmed to 

20 control the overall operation of the trusted device 24, and interact with the other 
functions on the trusted device 24 and with the other devices on the motherboard 20; 
a measurement function 31 for acquiring the integrity metric from the platform 10; a 
cryptographic function 32 for signing, encrypting or decrypting specified data; an 
authentication function 33 for authenticating a smart card; and interface circuitry 34 

25 having appropriate ports (36, 37 & 38) for connecting the trusted device 24 
respectively to the data bus 26, control lines 27 and address lines 28 of the 
motherboard 20. Each of the blocks in the trusted device 24 has access (typically via 
the controller 30) to appropriate volatile memory areas 4 and/or non-volatile memory 
areas 3 of the trusted device 24. Additionally, the trusted device 24 is designed, in a 

30 known manner, to be tamper resistant. 

For reasons of performance, the trusted device 24 may be implemented as an 
application specific integrated circuit (ASIC). However, for flexibility, the trusted 
device 24 is preferably an appropriately programmed micro-controller. Both ASICs 
and micro-controllers are well known in the art of microelectronics and will not be 

35 considered herein in any further detail. 
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One item of data stored in the non-volatile memory 3 of the trusted device 24 
is a certificate 350. The certificate 350 contains at least a public key 351 of the 
trusted device 24 and an authenticated value 352 of the platform integrity metric 
measured by a trusted party (TP). The certificate 350 is signed by the TP using the 
TP's private key prior to it being stored in the trusted device 24. In later 
communications sessions, a user of the platform 10 can verify the integrity of the 
platform 10 by comparing the acquired integrity metric with the authentic integrity 
metric 352. If there is a match, the user can be confident that the platform 10 has not 
been subverted. Knowledge of the TP's generally-available public key enables 
simple verification of the certificate 350. The non-volatile memory 35 also contains 
an identity (ID) label 353. The ID label 353 is a conventional ID label, for example a 
serial number, that is unique within some context. The ID label 353 is generally used 
for indexing and labelling of data relevant to the trusted device 24, but is insufficient 
in itself to prove the identity of the platform 10 under trusted conditions. 

The trusted device 24 is equipped with at least one method of reliably 
measuring or acquiring the integrity metric of the computing platform 10 with which it 
is associated. In the present embodiment, the integrity metric is acquired by the 
measurement function 31 by generating a digest of the BIOS instructions in the BIOS 
memory. Such an acquired integrity metric, if verified as described above, gives a 
potential user of the platform 10 a high level of confidence that the platform 10 has 
not been subverted at a hardware, or BIOS program, level. Other known processes, 
for example virus checkers, will typically be in place to check that the operating 
system and application program code has not been subverted. 

The measurement function 31 has access to: non-volatiie memory 3 for 
storing a hash program 354 and a private key 355 of the trusted device 24, and 
volatile memory 4 for storing acquired integrity metric in the form of a digest 361 . In 
appropriate embodiments, the volatile memory 4 may also be used to store the public 
keys and associated ID labels 360a-360n of one or more authentic smart cards 19s 
that can be used to gain access to the platform 10. 

In one preferred implementation, as well as the digest, the integrity metric 
includes a Boolean value, which is stored in volatile memory 4 by the measurement 
function 31, for reasons that will become apparent. 

A preferred process for acquiring an integrity metric will now be described 
with reference to Figure 4. 

In step 400, at switch-on, the measurement function 31 monitors the activity 
of the main processor 21 on the data, control and address lines (26, 27 & 28) to 
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determine whether the trusted device 24 is the first memory accessed. Under 
conventional operation, a main processor would first be directed to the BIOS memory 
first in order to execute the BIOS program. However, in accordance with the present 
embodiment, the main processor 21 is directed to the trusted device 24, which acts 
as a memory. In step 405, if the trusted device 24 is the first memory accessed, in 
step 410, the measurement function 31 writes to volatile memory 3 a Boolean value 
which indicates that the trusted device 24 was the first memory accessed. 
Otherwise, in step 415, the measurement function writes a Boolean value which 
indicates that the trusted device 24 was not the first memory accessed. 

In the event the trusted device 24 is not the first accessed, there is of course 
a chance that the trusted device 24 will not be accessed at all. This would be the 
case, for example, if the main processor 21 were manipulated to run the BIOS 
program first. Under these circumstances, the platform would operate, but would be 
unable to verify its integrity on demand, since the integrity metric would not be 
available. Further, if the trusted device 24 were accessed after the BIOS program 
had been accessed, the Boolean value would clearly indicate lack of integrity of the 
platform. 

In step 420, when (or if) accessed as a memory by the main processor 21, 
the main processor 21 reads the stored native hash instructions 354 from the 
measurement function 31 in step 425. The hash instructions 354 are passed for 
processing by the main processor 21 over the data bus 26. In step 430, main 
processor 21 executes the hash instructions 354 and uses them, in step 435, to 
compute a digest of the BIOS memory 29, by reading the contents of the BIOS 
memory 29 and processing those contents according to the hash program. In step 
440, the main processor 21 writes the computed digest 361 to the appropriate non- 
volatile memory location 4 in the trusted device 24. The measurement function 31, in 
step 445, then calls the BIOS program in the BIOS memory 29, and execution 
continues in a conventional manner. 

Clearly, there are a number of different ways in which the integrity metric may 
be calculated, depending upon the scope of the trust required. The measurement of 
the BIOS program's integrity provides a fundamental check on the integrity of a 
platform's underlying processing environment. The integrity metric should be of such 
a form that it will enable reasoning about the validity of the boot process - the value 
of the integrity metric can be used to verify whether the platform booted using the 
correct BIOS. Optionally, individual functional blocks within the BIOS could have 
their own digest values, with an ensemble BIOS digest being a digest of these 
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individual digests. This enables a policy to state which parts of BIOS operation are 
critical for an intended purpose, and which are irrelevant (in which case the individual 
digests must be stored in such a manner that validity of operation under the policy 
can be established). 

Other integrity checks could involve establishing that various other devices, 
components or apparatus attached to the platform are present and in correct working 
order. In one example, the BIOS programs associated with a SCSI controller could 
be verified to ensure communications with peripheral equipment could be trusted. In 
another example, the integrity of other devices, for example memory devices or co- 
processors, on the platform could be verified by enacting fixed challenge/response 
interactions to ensure consistent results. Where the trusted device 24 is a separable 
component, some such form of interaction is desirable to provide an appropriate 
logical binding between the trusted device 14 and the platform. Also, although in the 
present embodiment the trusted device 24 utilises the data bus as its main means of 
communication with other parts of the platform, it would be feasible, although not so 
convenient, to provide alternative communications paths, such as hard-wired paths 
or optical paths. Further, although in the present embodiment the trusted device 24 
instructs the main processor 21 to calculate the integrity metric in other 
embodiments, the trusted device itself is arranged to measure one or more integrity 
metrics. 

Preferably, the BIOS boot process includes mechanisms to verify the integrity 
of the boot process itself. Such mechanisms are already known from, for example, 
Intel's draft "Wired for Management baseline specification v 2.0 - BOOT Integrity 
Service", and involve calculating digests of software or firmware before loading that 
software or firmware. Such a computed digest is compared with a value stored in a 
certificate provided by a trusted entity, whose public key is known to the BIOS. The 
software/firmware is then loaded only if the computed value matches the expected 
value from the certificate, and the certificate has been proven valid by use of the 
trusted entity's public key. Otherwise, an appropriate exception handling routine is 
invoked. 

Optionally, after receiving the computed BIOS digest, the trusted device 24 
may inspect the proper value of the BIOS digest in the certificate and not pass 
control to the BIOS if the computed digest does not match the proper value. 
Additionally, or alternatively, the trusted device 24 may inspect the Boolean value 
and not pass control back to the BIOS if the trusted device 24 was not the first 
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memory accessed. In either of these cases, an appropriate exception handling 
routine may be invoked. 

Figure 5 illustrates the flow of actions by a TP, the trusted device 24 
incorporated into a platform, and a user (of a remote platform) who wants to verify 
5 the integrity of the trusted platform. It will be appreciated that substantially the same 
steps as are depicted in Figure 5 are involved when the user is a local user. In either 
case, the user would typically rely on some form of software application to enact the 
verification. It would be possible to run the software application on the remote 
platform or the trusted platform. However, there is a chance that, even on the remote 

10 platform, the software application could be subverted in some way. Therefore, it is 
anticipated that, for a high level of integrity, the software application would reside on 
a smart card of the user, who would insert the smart card into an appropriate reader 
for the purposes of verification. 

At the first instance, a TP, which vouches for trusted platforms, will inspect 

15 the type of the platform to decide whether to vouch for it or not. This will be a matter 
of policy. If all is well, in step 500, the TP measures the value of integrity metric of 
the platform. Then, the TP generates a certificate, in step 505, for the platform. The 
certificate is generated by the TP by appending the trusted device's public key, and 
optionally its ID label, to the measured integrity metric, and signing the string with the 

20 TP's private key. 

The trusted device 24 can subsequently prove its identity by using its private 
key to process some input data received from the user and produce output data, 
such that the input/output pair is statistically impossible to produce without 
knowledge of the private key. Hence, knowledge of the private key forms the basis 

25 of identity in this case. Clearly, it would be feasible to use symmetric encryption to 
form the basis of identity. However, the disadvantage of using symmetric encryption 
is that the user would need to share his secret with the trusted device. Further, as a 
result of the need to share the secret with the user, while symmetric encryption would 
in principle be sufficient to prove identity to the user, it would insufficient to prove 

30 identity to a third party, who could not be entirely sure the verification originated from 
the trusted device or the user. 

In step 510, the trusted device 24 is initialised by writing the certificate 350 
into the appropriate non-volatile memory locations 3 of the trusted device 24. This is 
done, preferably, by secure communication with the trusted device 24 after it is 

35 installed in the motherboard 20. The method of writing the certificate to the trusted 
device 24 is analogous to the method used to initialise smart cards by writing private 
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keys thereto. The secure communications is supported by a 'master key', known 
only to the TP, that is written to the trusted device (or smart card) during 
manufacture, and used to enable the writing of data to the trusted device 24; writing 
of data to the trusted device 24 without knowledge of the master key is not possible. 
5 At some later point during operation of the platform, for example when it is 

switched on or reset, in step 515, the trusted device 24 acquires and stores the 
integrity metric 361 of the platform. 

When a user wishes to communicate with the platform, in step 520, he 
creates a nonce, such as a random number, and, in step 525, challenges the trusted 

10 device 24 (the operating system of the platform, or an appropriate software 
application, is arranged to recognise the challenge and pass it to the trusted device 
24, typically via a BIOS-type call, in an appropriate fashion). The nonce is used to 
protect the user from deception caused by replay of old but genuine signatures 
(called a 'replay attack') by untrustworthy platforms. The process of providing a 

15 nonce and verifying the response is an example of the well-known 
'challenge/response' process. 

In step 530, the trusted device 24 receives the challenge and creates an 
appropriate response. This may be a digest of the measured integrity metric and the 
nonce, and optionally its ID label. Then, in step 535, the trusted device 24 signs the 

20 digest, using its private key, and returns the signed digest, accompanied by the 
certificate 350, to the user. 

In step 540, the user receives the challenge response and verifies the 
certificate using the well known public key of the TP. The user then, in step 550, 
extracts the trusted device's 24 public key from the certificate and uses it to decrypt 

25 the signed digest from the challenge response. Then, in step 560, the user verifies 
the nonce inside the challenge response. Next, in step 570, the user compares the 
computed integrity metric, which it extracts from the challenge response, with the 
proper platform integrity metric, which it extracts from the certificate. If any of the 
foregoing verification steps fails, in steps 545, 555, 565 or 575, the whole process 

30 ends in step 580 with no further communications taking place. 

Assuming all is well, in steps 585 and 590, the user and the trusted platform 
use other protocols to set up secure communications for other data, where the data 
from the platform is preferably signed by the trusted device 24. 

Further refinements of this verification process are possible. It is desirable 

35 that the challenger becomes aware, through the challenge, both of the value of the 
platform integrity metric and also of the method by which it was obtained. Both these 
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pieces of information are desirable to allow the challenger to make a proper decision 
about the integrity of the platform. The challenger also has many different options 
available - it may accept that the integrity metric is recognised as valid in the trusted 
device 24 , or may alternatively only accept that the platform has the relevant level of 
integrity if the value of the integrity metric is equal to a value held by the challenger 
(or may hold there to be different levels of trust in these two cases). 
The techniques of signing, using certificates, and challenge/response, and using 
them to prove identity, are well known to those skilled in the art of security and 
therefore need not be described in any more detail herein. 

A processing part 60 of a logon smart card 19 is illustrated in Figure 6. As 
shown, the logon smart card 19 processing part 60 has the standard features of a 
processor 61, memory 62 and interface contacts 63. The processor 61 is 
programmed for simple challenge/response operations involving authentication of the 
logon smart card 19 and verification of the platform 10, as will be described below. 
The memory 62 contains its private key 620, its public key 628, a user profile 621, 
the public key 622 of the TP and an identity 627. The user profile 621 lists the 
allowable auxiliary smart cards 17 AC1-ACn usable by the user, and the individual 
security policy 624 for the user. For each auxiliary smart card 17, the user profile 
includes respective identification information 623, the trust structure 625 between the 
smart cards (if one exists) and, optionally, the type or make 626 of the smart card. 

In the user profile 621, each auxiliary smart card 17 entry AC1-ACn includes 
associated identification information 623, which varies in dependence upon the type 
of card. For example, identification information for a cash card typically includes a 
simple serial number, whereas, for a crypto card, the identification information 
typically comprises the public key (or certificate) of the crypto card (the private key 
being stored secretly on the crypto card itself). 

The 'security policy* 624 dictates the permissions that the user has on the 
platform 10 while using an auxiliary smart card 17. For example, the user interface 
may be locked or unlocked while an auxiliary smart card 17 is in use, depending on 
the function of the auxiliary smart card 17. Additionally, or alternatively, certain files 
or executable programs on the platform 10 may be made accessible or not, 
depending on how trusted a particular auxiliary smart card 17 is. Further, the 
security policy 624 may specify a particular mode of operation for the auxiliary smart 
card 17, such as 'credit receipt* or 'temporary delegation', as will be described below. 

A 'trust structure' 625 defines whether an auxiliary smart card 17 can itself 
'introduce' further auxiliary smart cards 17 into the system without first re-using the 
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logon smart card 19. In the embodiments described in detail herein, the only defined 
trust structure is between the logon smart card 19 and the auxiliary smart cards 17 
that can be introduced to the platform 10 by the logon smart card 19. Introduction 
may be 'single session' or 'multi-session', as will be described below. However, 
5 there is no reason why certain auxiliary smart cards 17 could not in practice introduce 
further auxiliary smart cards 17. This would require an auxiliary smart card 17 to 
have an equivalent of a user profile listing the or each auxiliary smart card that it is 
able to introduce. 

A preferred process for authentication between a logon smart card 19 and a 

10 platform 10 will now be described with reference to the flow diagram in Figure 7. As 
will be described, the process conveniently implements a challenge/response routine. 
There exist many available challenge/response mechanisms. The implementation of 
an authentication protocol used in the present embodiment is mutual (or 3-step) 
authentication, as described in ISO/IEC 9798-3. Of course, there is no reason why 

15 other authentication procedures cannot be used, for example 2-step or 4-step, as 
also described in ISO/IEC 9798-3. 

Initially, the user inserts their logon smart card 19 into the smart card reader 
12 of the platform 10 in step 700. Beforehand, the platform 10 will typically be 
operating under the control of its standard operating system and executing the 

20 authentication process, which waits for a user to insert their logon smart card 19. 
Apart from the smart card reader 12 being active in this way, the platform 10 is 
typically rendered inaccessible to users by 'locking' the user interface (i.e. the screen, 
keyboard and mouse). 

When the logon smart card 19 is inserted into the smart card reader 12, the 

25 trusted device 24 is triggered to attempt mutual authentication in step by generating 
and transmitting a nonce A to the logon smart card 19 in step 705. A nonce, such as 
a random number, is used to protect the originator from deception caused by replay 
of old but genuine responses (called a 'replay attack') by untrustworthy third parties. 
In response, in step 710, the logon smart card 19 generates and returns a 

30 response comprising the concatenation of: the plain text of the nonce A, a new nonce 
B generated by the logon smart card 19, the ID 353 of the trusted device 24 and 
some redundancy; the signature of the plain text, generated by signing the plain text 
with the private key of the logon smart card 19; and a certificate containing the ID 
and the public key of the logon smart card 19. 

35 The trusted device 24 authenticates the response by using the public key in 

the certificate to verify the signature of the plain text in step 715. If the response is 
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not authentic, the process ends in step 720. If the response is authentic, in step 725 
the trusted device 24 generates and sends a further response including the 
concatenation of: the plain text of the nonce A, the nonce B, the ID 627 of the logon 
smart card 19 and the acquired integrity metric; the signature of the plain text, 
5 generated by signing the plain text using the private key of the trusted device 24; and 
the certificate comprising the public key of the trusted device 24 and the authentic 
integrity metric, both signed by the private key of the TP. 

The logon smart card 19 authenticates this response by using the public key 
of the TP and comparing the acquired integrity metric with the authentic integrity 

10 metric, where a match indicates successful verification, in step 730. If the further 
response is not authentic, the process ends in step 735. 

If the procedure is successful, both the trusted device 24 has authenticated 
the logon smart card 19 and the logon smart card 19 has verified the integrity of the 
trusted platform 10 and, in step 740, the authentication process executes the secure 

15 process for the user. Then, the authentication process sets an interval timer in step 
745. Thereafter, using appropriate operating system interrupt routines, the 
authentication process services the interval timer periodically to detect when the 
timer meets or exceeds a pre-determined timeout period in step 750. 

Clearly, the authentication process and the interval timer run in parallel with 

20 the secure process. 

When the timeout period is met or exceeded, the authentication process 
triggers the trusted device 24 to re-authenticate the logon smart card 19, by 
transmitting a challenge for the logon smart to identify itself in step 760. The logon 
smart card 19 returns a certificate including its ID 627 and its public key 628 in step 

25 765. In step 770, if there is no response (for example, as a result of the logon smart 
card 19 having been removed) or the certificate is no longer valid for some reason 
(for example, the logon smart card has been replaced with a different smart card), 
the session is terminated by the trusted device 24 in step 775. Otherwise, in step 
770, the process from step 745 repeats by resetting the interval timer. 

30 A preferred, general process for introducing an auxiliary smart card 17 into a 

platform 10 will now be described with reference to the flow diagram in Figure 8. 

When the secure process running on the platform 10 reaches a point where 
the logon smart card 19 needs to be replaced by an auxiliary smart card 17, for 
example at the time a cash card is needed to credit the platform 10 with funds for a 

35 remote transaction, in step 805 the secure process retrieves the user profile from the 
trusted device 24 and stores it in its volatile memory 35. The trusted device 24 then 
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extracts the details of the auxiliary smart cards 17 from the user profile and returns 
the details to the secure process in step 810. In step 815, the secure process 
displays an option list of auxiliary smart cards 17 and asks the user to select one. 
The secure process receives the users selection in step 820 and displays a message 
asking the user to replace the logon smart card 1 9 with the (or one of the) selected 
auxiliary smart card(s) 17 in step 825. As soon as the user ejects the logon smart 
card 19, the trusted device locks the user interface in step 830 and, in step 835, the 
secure process initialises the authentication process interval timer with a new timeout 
period, which determines the allowable duration of the auxiliary smart card session. 

[In parallel with the operation of the secure process, which has been 
described with reference to Figure 7), if the timeout period expires before the logon 
smart card 19 has been reinstated, the authentication process suspends the session 
(i.e. the secure process) and provides the user with an appropriate message. The 
authentication process has the authority to suspend the secure process, since it 
executed the secure process in the first instance. Clearly, the new timeout period 
needs to be sufficient for the required purposes, and may be configurable by a 
system administrator for this reason.] 

When the user inserts the selected auxiliary smart card 17, the trusted device 
24 is triggered to send the auxiliary smart card 17 a challenge to identify itself in step 
840. The auxiliary smart card 17 responds by returning its identity information to the 
trusted device 24 in step 845. The trusted device 24 then verifies the identity 
information by comparing it with the stored user profile information in step 850. 

If the trusted device 24 is unable to verify the auxiliary smart card 17 for any 
reason, in step 855 the session ends and the secure process displays an appropriate 
message for the user. Otherwise, in steps 860 and 865, the secure process interacts 
with the auxiliary smart card 17 as required. 

When the interaction is complete, in step 870, the secure process displays a 
prompt to the user to replace the auxiliary smart card 17 with the logon smart card 
19. When the user ejects the auxiliary smart card 17 form the smart card reader 12 
and inserts the logon smart card 19, the trusted device 24 is triggered to authenticate 
the logon smart card 19, by executing from step 760 in Figure 7, as described above, 
resulting in the session ending in step 775 or continuing in step 745. 

Additionally, or alternatively, in some embodiments it may be required that the 
user profile is encrypted and signed to protect privacy and integrity. If so, a secure 
data transfer protocol may be needed between the trusted device 24 and the logon 
smart card 19. There exist many available mechanisms for transferring secure 
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credentials between two entities. A possible implementation, which may be used in 
the present embodiment, is secure key transport mechanisms from ISO/IEC DIS 
11770-3. 

Clearly, the operation of the process that has just been described for 
5 introducing an auxiliary smart card 17 may vary in dependence upon the type of the 
auxiliary smart card 17; for example, whether it is a cash card or a crypto card. 
Variations in process for different types of auxiliary smart card 17 will now be 
described. 

10 CREDIT RECEIPT MODE 

A credit receipt mode allows a user to remove the logon smart card 19 for a 
very brief period of time (say 2 minutes, which is configurable by a system 
administrator or a user) from the smart card reader 12 to allow credits (or cash 
values) from a cash card to be transferred to the trusted device 24 of the platform 10 
15 without undue security risk. 

Figure 9 illustrates the process for enacting credit receipt mode. The steps 
that correspond to those illustrated in Figure 8 will not be specifically described 
again. 

It is assumed that a user profile that lists auxiliary smart cards 17 including 
20 cash cards is stored in the logon smart card 19. As before, when a user invokes an 
application that requires cash values, the secure process displays a request for the 
user to choose a cash card from those listed in the user profile. 

The first difference between the credit receipt mode process and the process 
in Figure 8 is that in step 921 the secure process displays a further request for the 
25 user to enter the amount of the credit transfer. The secure process receives the 
entered amount in step 922 and forwards a respective value to the trusted device 24 
in step 923. The trusted device 24 transfers the credits from the cash card to the 
trusted device 24 in steps 960 and 965, after the cash card has been inserted and 
authenticated. 

30 As an alternative or additional feature, depending on the security policy, 

unauthorised cash cards may also be used; for example, there may be an option 
"Others" in the list of authorised cash cards. Clearly, the risks associated with 
receiving credits from any auxiliary smart card 17 are relatively low. 

Typically, only a relatively short time is required to enact the whole process of 

35 transferring the credits. The length of the timeout period is determined by the 
security policy in the user profile. If the timeout is exceeded, the transfer process is 
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aborted and the user interface is temporarily locked. On the other hand, if the user 
reinserts the logon smart card 19 within the specified time-limit, a new round of 
authentication is performed between the smart card and the platform 10. Upon 
successful verification, the user interface will be unlocked and the original session, 
5 i.e. before the credit transfer mode, resumes, but with the cash value now stored in 
the trusted device 24. The cash value may be used for, for example, electronic 
commerce. 

Since the user interface is essentially locked during the credit transfer mode, 
and is re-activated only after the re-insertion of the logon smart card 19, the host 
10 platform 10 does not suffer any serious security risk in the credit receipt mode. 
Further, since the user has to authenticate which cash card to use, using the logon 
smart card 19, abuse of cash cards by illegal users is also minimised. 

TEMPORARY DELEGATION MODES 

15 It will be appreciated that for a crypto card to function (say for encryption, 

decryption, signature and verification), it potentially needs to be inserted in the place 
of a logon card for a substantial amount of time, unlike for cash cards. To address 
the need for potentially greater periods of time to use a crypto card, the present 
embodiment includes what is referred to as a temporary delegation mode, which 

20 allows a user to use crypto cards in place of the logon card for an undefined time, 
subject to possible respective security policy limitations. Temporary delegation 
modes will now be described with reference to the flow diagram in Figure 10. The 
steps that correspond to those illustrated in Figure 8 will not be specifically described 
again. 

25 To invoke a temporary delegation mode, a user (or the secure process) 

selects a temporary delegation mode in step 1000 while the logon smart card 19 is 
being used. In response, the host platform 10 takes the steps to receive and 
authenticate the auxiliary smart card 17, which in this example is a crypto card. 

When provided with a list of allowable crypto cards, the user specifies the 

30 authorised crypto card. Depending on the security policy, unregistered crypto cards 
may or may not be used. Again, if the user profile is encrypted, a secure data 
transfer protocol (again, as discussed in ISO/IEC DIS 1 1770-3) may be employed. 

After the logon smart card 19 is removed, the user interface is locked and a 
the secure process displays a message requesting a new smart card. 

35 Upon insertion and authentication of the specified crypto card, the secure 

process activates user privileges in step 1033 consistent with the security policy of 
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the crypto card. For example, the user may need to use the user interface for entry 
of certain information related to the crypto card operation, but should not be able to 
execute any other process or perform any other operation. 

When the crypto card is removed from the smart card reader 12, the user 
interface is locked again, until the logon smart card 19 is inserted and authenticated. 

The example of the temporary delegation mode described above allows a 
single auxiliary smart card 17 to be used in a 'single session' in place of the logon 
smart card 19 for an undefined period of time. 

An alternative, or additional, temporary delegation mode permits multiple 
auxiliary smart cards 17 to be used in turn, in place of the logon smart card 19, 
without the need to re-insert the logon smart card 19. An example of such a 'multi- 
session' temporary delegation mode will now be described with reference to Figure 
11. As before, the steps that correspond to those illustrated in Figure 8 will not be 
specifically described again. 

In a multi-session, multiple auxiliary smart cards 17 can be freely used in 
place of the logon smart card 19, thus allowing maximal convenience of use. 

To invoke a multi-session temporary delegation mode, a user (or the secure 
process) selects a multi-session temporary delegation mode in step 1100 while the 
logon smart card 19 is being used. 

A significant difference between a multi-session temporary delegation mode 
and the single session temporary delegation mode is that, when provided with the list 
of available authorised auxiliary smart cards 17 in step 1115, the user can select 
multiple authorised auxiliary smart cards 17 in step 1120. The selected auxiliary 
smart cards 17 may be of different kinds depending on the user's requirements. 

The host platform 10 takes the steps to receive and authenticate any one of 
the selected auxiliary smart cards 17. 

As soon as the logon smart card 19 is ejected the user interface is locked, the 
secure process activates user privileges consistent with the operation of that auxiliary 
smart card 17 in step 1133. When the auxiliary smart card 17 is eventually ejected, 
the process loops to step 1125, a message is generated to replace the card and the 
user interface is locked again in step 1130. When the next auxiliary smart card 17 is 
inserted, the secure process activates user privileges consistent with the operation of 
that auxiliary smart card 17 in step 1 133 again. 

This procedure may be repeated for any of the selected auxiliary smart cards 
17 until the session ends or the logon smart card is re-inserted in step 1 175. In other 
words, the user can use any combination of the selected auxiliary smart cards 17 
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without the need of the insertion of the logon smart card 19 during the whole multi- 
session. Clearly, such a permissive multi-session is very convenient for the user, 
although the benefits need to be weighed against the risks of such freedom. 

Note that a security control policy described in the user profile may give 
5 constraints on the number, types and makes of smart cards allowed in a multi- 
session as well as any time-limits. Typically, different auxiliary smart cards 17 give 
the user different sets of privileges. For instance, some sensitive files may be locked 
whenever the auxiliary smart card 17 currently being used is regarded to be not 
trustworthy enough. Indeed, any truly sensitive application may require the insertion 

10 of the logon smart card 1 9 again for authentication. 

Since it is not easy to estimate how long a temporary delegation mode will 
last, in theory, it might be acceptable to have no timeout period as such, as in the 
examples above. However, there are risks associated with such a policy, for 
example a user may leave the platform 10 during a temporary delegation mode 

15 session. Therefore, it is preferable to have an overall timeout period, fixed for the 
temporary delegation mode session, which overrides both the normal re- 
authentication timeout period of the authentication process and the individual timeout 
periods associated each auxiliary smart card 17. Additionally, it might also be 
possible to have individual timeout periods for certain auxiliary smart cards 17. As 

20 usual, the specification of the timeout period(s) will be determined by the security 
policies for the auxiliary smart cards 17. In practice, the timeout period for a 
temporary delegation mode is implemented by the secure process overriding the 
authentication process. Exemplary fixed session timeout periods for temporary 
delegation modes are 30 minutes, 1 hour or 2 hours. The period(s) can be set or 

25 modified by the user or a system administrator, and may depend on the 
trustworthiness of the platform 10. 

Re-insertion of the original logon card will typically be needed for extending 
the temporary delegation mode session, and, generally, the secure process issues a 
warning message to the user prior to expiration. This is analogous to request for 

30 insertion of coins in a phone booth during phone calls. Upon expiration, the user 
interface will be locked and can be unlocked only by the logon card. If a user 
attempts to use a time-consuming application in a temporary delegation mode, the 
secure process may request the insertion of a logon smart card 19 beforehand to 
avoid locking the user interface in the middle of an application. 

35 There are a variety of possible, different temporary delegation modes that 

generally specify the class of auxiliary smart cards 17 and applications allowed 
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during the temporary delegation mode. For instance, in some modes, perhaps only a 
single type of auxiliary smart card 17 (possibly with traceable ID) is allowed. In other 
modes, only a small class of auxiliary smart cards 17 is allowed. In yet other modes, 
a large class of auxiliary smart cards 17 is allowed. 
5 The exact set of privileges that can be delegated is a function of the system 

security policy, a choice by the user (in set-up and/or during the session itself), and 
the type and make of the auxiliary card being used. Some privileges may be revoked 
during a temporary delegation mode. For instance, some files (currently on screen or 
otherwise) may become locked once . the temporary delegation mode is employed. 

10 High security applications might request the re-insertion of the original logon card. In 
an extreme case, all privileges except for the specific application may be temporarily 
suspended during the temporary delegation mode. 

As an alternative, or in addition, to the embodiments described above, the 
logon smart card 19 may be programmed to categorise different platform 10s. For 

15 example, platform 10s may be categorised as "fairly trustworthy", "very trustworthy", 
or "extremely trustworthy", depending on the type of the platform 10. In this case, the 
platform 10 type will be revealed by the identity information received by the logon 
smart card 19 from the platform 10. The logon smart card 19 is programmed to 
compare the identity information with pre-determined, stored information, where a 

20 particular match indicates the category of the platform 10. Conveniently, the stored 
category information forms part of the user profile. 

The security policy that the logon smart card 19 adopts with a particular 
platform 10 then depends on the category of the platform 10. In one example, the 
logon smart card 19 may transmit different user profile information to the platform 10 

25 depending on the platform 10's category. For example, with a "fairly trustworthy" 
platform 10, the smart card might only pass information relating to crypto cards to the 
platform 10, to restrict the user to only being able to send and receive encrypted 
emails, or surf the Internet. Additionally, for "fairly trustworthy" platform 10s, the user 
profile information may limit to 'single-session 1 temporary delegation modes. In 

30 contrast, a "very trustworthy" platform 10 may receive user profile information that 
permits multi-session temporary delegation modes and even cash card transactions. 
Finally, an "extremely trusted" platform 10 would receive user profile information to 
permit all possible actions including multi-session and cash card transactions but 
also other administrative functions. 

35 An example of an administrative function, requiring an "extremely trusted" 

platform 10, is the ability to create or modify the user profile of a logon smart card 19. 
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24 



When a logon smart card 19 verifies that a platform 10 is an "extremely trusted" 
platform 10, it passes user profile information to the platform 10 that includes an 
option to allow the user to select, from the secure process, a profile modification 
option. When the user selects the registration process, a special smart card 
registration process 'wizard' is displayed. This wizard allows the user to add a new 
auxiliary smart card 17, delete an existing auxiliary smart card 17, and view the 
detailed information of each auxiliary smart card 17's ID, such as its public key or 
certificate. In the user profile, each registered smart card has a distinguished 
number and name given during its registration. 'Wizards' are well known in the art of 
computer applications, and will not be described in any further detail herein. 

In alternative embodiments, the user profile information may be stored in the 
trusted device 24 or in a remotely located trusted platform 10. Such arrangements 
would typically require different mechanisms for controlling access by the secure 
process or platform 10 to the user profile information, but the use of the information 
once accessed would remain the same. 

The present invention is not limited in application to smart cards (or other 
security tokens), which interact passively with a platform. The invention is applicable 
also to smart cards which can initiate a command to a platform (or trusted device on 
a platform), communicate with the trusted device for exchange of messages and 
information, send requests for information, and receive results from the trusted 
device in response to those requests. Implementation of initiation of user commands 
from a smart card is known in "Smartcards - from Security Tokens to Intelligent 
Adjuncts", by Boris Balacheff, Bruno Van Wilder and David Chan, published in 
CARDIS 1998 Proceedings. 

Similarly, the interpretation of integrity measurements provided by the trusted 
device may not be achieved by the user, as represented by a smart card or 
otherwise. An appropriate solution is for a user smart card to have access (typically 
through the platform) to a trusted third party server which provides this functionality. 
This can be an advantageous solution because of the limited processing power and 
memory available on most smart cards. In this arrangement, the integrity metrics 
data is sent not to the smart card but to a remote server trusted by the smart card. 
The remote server verifies that the integrity metrics data provided by the trusted 
device is correct by comparing it with a set of expected integrity metrics. The 
expected integrity metrics may be supplied by the trusted device itself from pre- 
stored data within it, or where the platform is of a common type, the trusted server 
may store sets of expected integrity metrics for that type of computer platform. In 
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either case, the trusted server performs the heavy computational data processing 
required for verification of the integrity metrics with the expected integrity metrics, 
and digitally signs the result of the verification. This is sent back to the smart card, 
which then may either accept or reject the digital signature, and hence the verification 
5 result. 

While the invention has been described with reference to several preferred 
embodiments, it will be appreciated that various modifications can be made to the 
parts and methods that comprise the invention without departing from the spirit and 
scope thereof. 



10 
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CLAIMS 

1 . Computing apparatus comprising: 

memory means storing the instructions of a secure process and an 
5 authentication process; 

processing means arranged to control the operation of the computing 
apparatus including by executing the secure process and the authentication process; 

user interface means arranged to receive user input and return to the user 
information generated by the processing means in response to the user input; and 
10 interface means for receiving a removable primary token and communicating 

with the token, the token comprising a body supporting: 

a token interface for communicating with the interface means; 

a token processor; and 

token memory storing token data including information for identifying the 
15 token and auxiliary token information identifying one or more authorised auxiliary 
tokens, 

wherein the processing means is arranged to receive the identity information 
and the auxiliary token information from the primary token, authenticate the token 
using the authentication process and, if the token is successfully authenticated, 
20 permit a user to interact with the secure process via the user interface means, 

and wherein the processing means is arranged to repeatedly authenticate the 
primary token and cause the computing platform to suspend interaction between the 
secure process and the user if authentication is not possible as a result of the 
removal of the primary token unless the primary token is replaced by an authorised 
25 auxiliary token. 

2. Computing apparatus according to claim 1, arranged to generate information 
representing the integrity of the computing apparatus and transmit the integrity 
information to the primary token, wherein the token processor is programmed to 

30 verify the integrity of the computing apparatus including by using the integrity 
information. 

3. Computing apparatus according to claim 1 or claim 2, wherein the authorised 
token is a cash token and the secure process is arranged to credit or debit the token. 

35 
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4. Computing apparatus according to claim 1 or claim 2, wherein the authorised 
token is a crypto token programmed to encrypt, decrypt or sign data, and the secure 
process is arranged to transmit data to the crypto token to be encrypted, decrypted or 
signed and receive encrypted, decrypted or signed data from the crypto token. 

5 

5. Computing apparatus according to any preceding claim, arranged, only if the 
different token is an authorised auxiliary token, to allow the user to interact with the 
secure process. 

10 6. Computing apparatus according to any of claims 1 to 5, further comprising timer 
means programmed with a timeout period, wherein, in the event the different token is 
an authorised auxiliary token, the computing apparatus resets the timer and 
continues operation until the timeout period expires, after which time the computing 
apparatus suspends any interactions between the secure process and either or both 

15 the user and the authorised auxiliary token. 

7. Computing apparatus according to claim 6, arranged to recommence said 
interactions in the event the authorised auxiliary token is replaced by the primary 
token and the computing apparatus is able to authenticate the primary token. 

20 

8. Computing apparatus according to any preceding claim, arranged to permit 
interaction between the secure process and only one authorised auxiliary token after 
removal of the primary token. 

25 9. Computing apparatus according to any of claims 1 to 7, arranged to permit 
interaction between the secure process and more than one authorised auxiliary token 
after removal of the primary token. 

10. Computing apparatus according to any one of the preceding claims, wherein the 
30 processing means comprises a main processing unit and a secure processing unit 

and the memory means comprises main memory and secure memory. 

11. Computing apparatus according to claim 10, comprising a trusted device 
incorporating the secure processing unit and the secure memory, wherein the trusted 

35 device is programmed to authenticate the primary token repeatedly. 
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12. Computing apparatus according to claim 11, wherein the trusted device is 
arranged to acquire an integrity metric of the computing apparatus, and the primary 
token is arranged to use the integrity metric on at least one occasion to verify the 
integrity of the computing apparatus. 

13. Computing apparatus according to any one of the preceding claims, wherein the 
primary token comprises a smart card, and the interface means is configured to 
receive a smart card. 

14. Computing apparatus according to any one of the preceding claims, wherein the 
auxiliary token information is stored in a user profile. 



15. A method of controlling computing apparatus to authenticate a user, comprising 
the steps: 

15 the computing apparatus receiving a primary token of the user, the primary 

token containing information suitable for authenticating the primary token , and 
information relating to one or more authorised auxiliary tokens; 

if the token is authentic, permitting the user to interact with one or more 
secure applications that may be executed by the computing platform; 
20 at intervals, re-authenticating the primary token; and 

if it is not possible to re-authenticate the primary token, suspending the 
interaction between the computing apparatus and the user unless the primary token 
has been replaced with an authorised auxiliary token. 

25 16. A method according to claim 15, further comprising the steps: 

the computing apparatus providing integrity metric information to the primary 

token; 

the primary token using the integrity metric information to verify the integrity of 
the computing apparatus; and 
30 if the primary token is unable to verify the integrity of the computing 

apparatus, suspending interaction between the computing apparatus and the user. 



17. A method according to claim 15 or claim 16, wherein the computing apparatus 
interaction with the authorised auxiliary token for a limited period of time. 

35 
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18. A method according to any of claims 15 to 17, wherein the computing apparatus 
only permits interaction with one authorised auxiliary token after removal of the 
primary token. 



5 19. A method according to any of claims 15 to 17, wherein the computing apparatus 
permits interaction with plural authorised auxiliary tokens after removal of the primary 
token. 



20. A smart card programmed for operation as a primary token in accordance with 
10 any one of claims 15 to 19. 

21. Computing apparatus configured for operation in accordance with any one of 
claims 15 to 19. 



15 
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